Using a trusted platform module for boot policy and secure firmware

ABSTRACT

Embodiments of apparatuses and methods for using a trusted platform module for boot policy and secure firmware are disclosed. In one embodiment, a trusted platform module includes a non-volatile memory, a port, and a mapping structure. The port is to receive an input/output transaction from a serial bus. The transaction includes a system memory address in the address space of a processor. The mapping structure is to map the system memory address to a first location in non-volatile memory.

PRIORITY

This application is a continuation of U.S. patent application Ser. No.13/976,478 filed on Jun. 27, 2013 titled “USING A TRUSTED PLATFORMMODULE FOR BOOT POLICY AND SECURE FIRMWARE”, which is a 371 ofInternational PCT/US2011/068078 filed on Dec. 30, 2011 titled “USING ATRUSTED PLATFORM MODULE FOR BOOT POLICY AND SECURE FIRMWARE”.

BACKGROUND

1. Field

The present disclosure pertains to the field of information processing,and more particularly, to the field of security in informationprocessing systems.

2. Description of Related Art

A Trusted Platform Module (“TPM”) is a hardware component that providesa specific set of security functions to an information processingsystem. These functions include secure key generation and storage andauthenticated access to encrypted data. A TPM may be implementedaccording to specifications such as the TPM Main Specification Version1.2, published by the Trusted Computed Group and available from theInternet at www.trustedcomputinggroup.org.

The sub-components of a TPM may include an execution engine and securenon-volatile (“NV”) memory or storage. The secure NV memory may be usedto store sensitive information, such as encryption keys, and theexecution engine may be used to protect the sensitive informationaccording to the security policies dictated by the TPM's control logic.An inherent feature of a TPM is the control logic that implements accesscontrols which prevent unauthorized access to the NV memory. A TPM istypically accessed through a serial bus connection.

BRIEF DESCRIPTION OF THE FIGURES

The present invention is illustrated by way of example and notlimitation in the accompanying figures.

FIG. 1 illustrates a system and a TPM in which an embodiment of thepresent invention may be present and/or operate.

FIG. 2 illustrates a method for using a TPM for boot policy and securefirmware according to an embodiment of the present invention.

DETAILED DESCRIPTION

Embodiments of apparatuses, methods, and systems for using a TPM forboot policy and secure firmware are described below. In thisdescription, numerous specific details, such as component and systemconfigurations, may be set forth in order to provide a more thoroughunderstanding of the present invention. It will be appreciated, however,by one skilled in the art, that the invention may be practiced withoutsuch specific details. Additionally, some well known structures,circuits, and the like have not been shown in detail, to avoidunnecessarily obscuring the present invention.

Embodiments of the present invention may be used for managing bootpolicy and for storing basic input/output system (“BIOS”) firmware andfirmware for platform components such as embedded controllers, takingadvantage of a TPM's strict access control features. Embodiments providefor a using the NV memory of a TPM to store such firmware, and adding amapping table to the TPM to provide for this NV memory space to beaccessed as memory mapped input/out (MMIO) memory space, so that aprocessor or other agent can access the firmware using instructionsand/or micro-instructions based on its standard instruction setarchitecture and microarchitecture, rather than requiring it to use thespecial access commands typically needed to access NV memory of a TPM.

FIG. 1 illustrates system 100, an information processing system in whichan embodiment of the present invention may be present and/or operate.System 100 may represent any type of information processing system, suchas a server, a desktop computer, a portable computer, a set-top box, ahand-held device, or an embedded control system. System 100 includesprocessor 110, embedded controller 120, bridge 130, and TPM 140. Systemsembodying the present invention may include number of each of thesecomponents and any other components or other elements. Any or all of thecomponents or other elements in any system embodiment may be connected,coupled, or otherwise in communication with each other through anynumber of buses, point-to-point, or other wired or wireless connections.

Processor 110 may represent any type of processor, including a generalpurpose microprocessor, such as a processor in the Core® ProcessorFamily, or other processor family from Intel Corporation, or anotherprocessor from another company, or any other processor for processinginformation according to an embodiment of the present invention.Processor 110 may include any number of execution cores and/or supportany number of execution threads, and therefore may represent any numberof physical or logical processors, and/or may represent amulti-processor component or unit.

Processor 110 may include instruction hardware 112, execution hardware114, interface 116, and control logic 118, plus any other desired unitsor elements.

Instruction hardware 112 may represent any circuitry, structure, orother hardware, such as an instruction decoder, for fetching, receiving,decoding, and/or scheduling instructions. Any instruction format may beused within the scope of the present invention; for example, aninstruction may include an opcode and one or more operands, where theopcode may be decoded into one or more micro-instructions ormicro-operations for execution by execution hardware 114. Executionhardware 114 may include any circuitry, structure, or other hardware,such as an arithmetic unit, logic unit, floating point unit, shifter,etc., for processing data and executing instructions,micro-instructions, and/or micro-operations.

Interface unit 116 may represent any circuitry, structure, or otherhardware, such as a bus unit or any other unit, port, or interface, toallow processor 110 to communicate with other components in system 100through any type of bus, point to point, or other connection, directlyor through any other component, such as a memory controller or a busbridge.

Control logic 118 may represent microcode, programmable logic,hard-coded logic, or any other type of logic to control the operation ofthe units and other elements of processor 110 and the transfer of datawithin processor 110. Control logic 118 may cause processor 110 toperform or participate in the performance of method embodiments of thepresent invention, such as the method embodiments described below, forexample, by causing processor 110 to execute instructions received byinstruction hardware 112 and micro-instructions or micro-operationsderived from instructions received by instruction hardware 112.

Embedded controller 120 may represent any embedded controller,microcontroller, or other component or device, the operation of whichmay include the use of firmware. Bridge 130 may represent any componentor device including circuitry or logic to provide for the communicationbetween components, devices, or other elements of system 100. Forexample, bridge 130 may include a bridge between a bus through whichprocessor 110 may access memory and a bus through which I/O devices maybe accessed. Therefore, bridge 130 may provide for forwarding MMIOtransactions from processor 110 through processor bus 132 to TPM 140through serial bus 134.

TPM 140 includes I/O port 141 for receiving TPM commands andcommunicating the results over a serial bus, such as a serial peripheralinterface (“SPI”) or low pin count (“LPC”) bus. Execution engine 142executes program code 143 in response to the TPM commands and utilizes avariety of different TPM components to perform the necessary operationsincluding a secure hash algorithm 1 (SHA-1) component 144 for performingSHA-1 hash operations; a random number generator 145 for generatingrandom numbers; an attestation identify key (AIK) component 146 forsecurely establishing that a remote entity is communicating with theTPM; an RSA engine 147 for implementing RSA encryption and digitalsignatures; and a key generation module 148 for generating keys.

TPM 140 also includes NV memory 150, mapping structure 151, and commandregister 152. Mapping structure 151 may be include any circuitry,structure, or other hardware or firmware to map storage locations in NVmemory 150 to addresses within the system memory space of system 100.Therefore, NV memory 150 may be accessed with memory transactions fromprocessor 110 or embedded controller 120, forwarded to serial bus 134through bridge 130 as MMIO transactions. The addresses may be receivedfrom serial bus 134 at I/O port 141, and mapped to a location in NVmemory 150 by mapping structure 151. Therefore, NV memory 150 may beused to store firmware that may be accessed and executed by processor110 or embedded controller 120 as if the firmware was stored in a flashmemory or other NV memory elsewhere in system 100. However, the accesscontrol mechanisms of TPM 140 provide a higher level of security thanthat of a flash memory or other NV memory elsewhere in system 100.

Therefore, NV memory 150 may be used to securely store boot policy andBIOS firmware that may be executed by processor 100 in response tomemory transactions initiated by control logic 118. Similarly, NV memory150 may be used to securely store firmware to be executed by embeddedcontroller 120 or other system components.

Command register 152 may be used to further control the mapping of theaddress received at I/O port 141 to a location in NV memory 150. Forexample, command register 152 may include bits or fields to be used toenable mapping by mapping structure 151 and/or to direct an access torecovery BIOS instead of standard BIOS.

FIG. 2 illustrate method 200 for using a TPM for boot policy and securefirmware according to an embodiment of the present invention. Thedescription of FIG. 2 may refer to elements of FIG. 1, but method 200and other method embodiments of the present invention are not intendedto be limited by these references.

In box 210, TPM 140 is configured with standard BIOS and recovery BIOSstored in NV memory 150. In box 212, mapping structure 151 is configuredto map the system memory addresses for BIOS to the correspondinglocations in NV memory 150 where standard BIOS and recovery BIOS havebeen stored. In box 214, command register 152 is configured to directBIOS accesses to standard BIOS instead of recovery BIOS.

In box 220, system 100 is powered on. In box 222, control logic 118directs instruction hardware 112 to fetch the first line of boot code.In box 224, interface 116 unit issues a memory transaction on processorbus 132 to fetch the first line of boot code. In box 226, bridge 130converts the transaction to a MMIO transaction on serial bus 134. In box228, I/O port 141 receives the transaction.

In box 230, mapping structure 151 maps the I/O address to a location inNV memory 150 at which the first line of boot code in standard BIOS hasbeen stored. In box 232, the first line of boot code is returned toinstruction hardware 111 through I/O port 141, serial bus 134, bridge130, processor bus 132, and interface 116 unit. In box 234, executionhardware 112 executes the first line of standard boot code. In box 236,processor 100 continues executing standard boot code from TPM 140.

In box 240, processor 110 issues a write transaction to command register152 to enable booting from recovery BIOS instead of standard BIOS. Inbox 242, the transaction is received by I/O port 141. In box 244,command register 152 is programmed to direct an access to the first lineof boot code to the NV memory location in which recovery BIOS has beenstored.

In box 250, system 100 experiences an event which requires a reboot. Inbox 252, control logic 118 directs instruction hardware 112 to fetch thefirst line of boot code. In box 254, interface unit 116 issues a memorytransaction on processor bus 132 to fetch the first line of boot code.In box 256, bridge 130 converts the transaction to a MMIO transaction onserial bus 134. In box 258, I/O port 141 receives the transaction.

In box 260, mapping structure 151 maps the I/O address to a location inNV memory 150 at which the first line of boot code in recovery BIOS hasbeen stored. In box 262, the first line of recovery boot code isreturned to instruction hardware 111 through I/O port 141, serial bus134, bridge 130, processor bus 132, and interface unit 116. In box 264,execution hardware 112 executes the first line of recovery boot code. Inbox 266, processor 100 continues executing recovery boot code from TPM140.

Within the scope of the present invention, the method illustrated inFIG. 2 may be performed in a different order, with illustrated boxesomitted, with additional boxes added, or with a combination ofreordered, omitted, or additional boxes.

Thus, apparatuses, methods, and systems for using a TPM for boot policyand secure firmware have been disclosed. While certain embodiments havebeen described, and shown in the accompanying drawings, it is to beunderstood that such embodiments are merely illustrative and notrestrictive of the broad invention, and that this invention not belimited to the specific constructions and arrangements shown anddescribed, since various other modifications may occur to thoseordinarily skilled in the art upon studying this disclosure. In an areaof technology such as this, where growth is fast and furtheradvancements are not easily foreseen, the disclosed embodiments may bereadily modifiable in arrangement and detail as facilitated by enablingtechnological advancements without departing from the principles of thepresent disclosure or the scope of the accompanying claims.

What claimed is:
 1. A trusted platform module comprising: non-volatilememory; a port to receive an input/output transaction from a serial bus,the transaction including a system memory address in the address spaceof a processor; and a mapping structure to map the system memory addressto a first location in non-volatile memory.
 2. The trusted platformmodule of claim 1, wherein the non-volatile memory is to store basicinput/output system code at the first location.
 3. The trusted platformmodule of claim 2, further comprising a command register to direct theinput/output transaction to a second location in non-volatile memoryinstead of the first location.
 4. The trusted platform module of claim3, wherein the non-volatile memory is to store standard basicinput/output system code in the first location.
 5. The trusted platformmodule of claim 4, wherein the non-volatile memory is to store recoverybasic input/output system code in the second location.
 6. A methodcomprising: receiving, by a trusted platform module, a firstinput/output transaction from a serial bus, the first input/outputtransaction including a first system memory address in the address spaceof a processor; and mapping, by the trusted platform module, the firstsystem memory address to a first location in non-volatile memory of thetrusted platform module.
 7. The method of claim 6, further comprisingstoring basic input/output system code at the first location.
 8. Themethod of claim 7, further comprising configuring a command register inthe trusted platform module to direct the first input/output transactionto a second location in the non-volatile memory instead of the firstlocation.
 9. The method of claim 8, further comprising storing standardbasic input/output system code at the first location.
 10. The method ofclaim 9, further comprising storing recovery basic input/output systemcode at the second location.
 11. The method of claim 6, furthercomprising configuring a mapping structure in the trusted platformmodule to map the first system memory address to the first location inthe non-volatile memory.
 12. The method of claim 11, further comprising:issuing, by the processor, a memory transaction to boot a system; andconverting, by a bridge, the memory transaction to the firstinput/output transaction.
 13. The method of claim 8, further comprisingissuing, by a processor, a write transaction to configure the commandregister.
 14. The method of claim 7, further comprising storing embeddedcontroller firmware at a third location in the non-volatile memory. 15.The method of claim 14, further comprising: issuing, by an embeddedcontroller, a memory transaction including a second system memoryaddress in the address space of the processor; converting, by a bridge,the memory transaction to a second input/output transaction; andmapping, by the trusted platform module, the second system memoryaddress to the third location.
 16. A system comprising: a processorincluding instruction hardware to fetch a first instruction from a firstsystem memory address in the address space of the processor, and aninterface unit to issue a first memory transaction including the firstsystem memory address; and a trusted platform module including:non-volatile memory, a port to receive a first input/output transactionfrom a serial bus, the transaction including the first system memoryaddress, and a mapping structure to map the first system memory addressto a first location in non-volatile memory.
 17. The system of claim 16,further comprising a bridge to convert the first memory transaction tothe first input/output transaction.
 18. The system of claim 16, whereinthe first instruction is the boot the system.
 19. The system of claim16, further comprising an embedded controller to issue a second memorytransaction including a second system memory address in the addressspace of the processor, wherein the mapping structure is also to map thesecond system memory address to a second location in non-volatilememory.
 20. The system of claim 19, wherein the first location is tostore basic input/output system code and the second location is to storeembedded controller firmware.